Home

Registrar

Links

Artigos

Empregos

Javeiros

Tutoriais

Forum

Entrevista

Top

Menu

· Home
· Arquivo
de Notícias
· Conteúdo
· Downloads
· Empregos
· Enviar
Notícia
· Feedback
· Procurar
· Recomende
o JF
· Sua
conta
· Top
· Top
Tutoriais
· Topics
· Web_Links

RSS JF

Recomendamos

User Info

Bem-vindo(a), Anônimo

(Login)
(Cadastre-se)

Cadastramento:
Último(a):
Pessoas on-line:
Visitantes: 117
Cadastrados: 2
Total: 119

On-line
agora:
01: vfpamp
02: Adriana
Cardoso

Official JUG

Wallpaper

Jugs Amigos

(Logo
rotatório)

Obtendo Qualidade de Software com o
RUP

Obtendo Qualidade de Software com o RUP

Ronaldo Rezende Vilela Luiz

Sistemas de Informação – Universidade de
Uberaba (UNIUBE)

Uberaba, MG - Brasil

[email-masked]

Abstract.This article describes what should be
considered in the software development to achieve acceptable
quality patterns. The article shows that quality software is
something that should be considered in all time in the
application life cycle. One of the features that can maximize
the software’s quality level is the iterative and incremental
development. Moreover, the failures of the waterfall
development process and the show and description of the
Rational Unified Process (RUP)’s features will be
approached.

Resumo. Este artigo descreve o que deve ser levado
em consideração no desenvolvimento de software para atingir
padrões de qualidade aceitáveis. O artigo mostra que a
qualidade de software é algo que deve ser levado em
consideração em todo momento do ciclo de vida do aplicativo.
Uma das características que podem elevar o nível de qualidade
do software é o desenvolvimento iterativo e incremental. Além
disso, são abordadas as falhas do processo de desenvolvimento
em cascata e a apresentação e descrição das características do
Rational Unified Process (RUP).

1. Introdução

A cada dia que passa, as organizações se tornam mais
dependentes dos sistemas de informação. Atualmente, não apenas
sistemas que podem colocar a vida de pessoas em risco são
considerados sistemas de missão crítica. Hoje, os sistemas de
informação de muitas empresas são qualificados como de missão
crítica, pois podem gerar enormes prejuízos financeiros caso
haja eventuais problemas com os mesmos.

A atividade de desenvolvimento de software possui um alto
grau de risco. Essa atividade já gerou grandes prejuízos no
passado e continua gerando. Atualmente, muitos projetos de
desenvolvimento de software são iniciados e não são
terminados, e outros são terminados consumindo prazos e
orçamentos bem acima do que foi estipulado no início do
projeto. Além disso, muitos produtos desenvolvidos possuem um
nível muito baixo de qualidade.

Conforme [Kruchten 2003], um produto de qualidade deve ter
ausência de defeitos e, principalmente, deve atender aos
propósitos desejados. Alguma coisa com qualidade deve fazer o
que as pessoas querem que ela faça. Se alguma coisa é livre de
defeitos, mas não faz o que as pessoas querem que ela faça,
essa coisa é um produto desnecessário.

A qualidade de software não pode ser avaliada de maneira
isolada. Softwares são desenvolvidos pelas organizações
através de procedimentos. Um método pobre ou a ausência de uma
metodologia pode ser a causa da baixa qualidade. Sendo assim,
a avaliação da qualidade está diretamente relacionada com a
qualidade de processos e metodologias utilizadas.

2. Metodologias de Desenvolvimento

Metodologias de desenvolvimento e estruturas de avaliação
de processos podem ser comparadas sob duas dimensões: de um
lado, temos o vértice pouca formalidade / muita formalidade e
de outro, o método cascata / método iterativo, exemplificado
através da Figura 1.

Figura 1 : Mapa de processos

Os processos com pouca formalidade produzem o mínimo de
documentação possível e procedimentos de trabalho bastante
informais. Os formais possuem maior documentação, mantém o
histórico dos artefatos gerados e possuem gerenciamento de
mudanças.

O método cascata é um procedimento linear, onde a
integração e os testes são feitos no fim do ciclo de
desenvolvimento. O método iterativo é guiado pelo risco, ou
seja, é voltado para a eliminação e minimização de riscos. A
implementação da arquitetura, a integração e os testes são
realizados desde o início do ciclo de vida do aplicativo.

2.1 Método Cascata

Esse método, também conhecido como seqüencial, ou linear,
foi utilizado por muitos anos e ainda é utilizado. Segundo
[Kroll e Kruchten 2003], esse processo se baseia nos seguintes
passos:

Entender completamente o problema a ser resolvido, seus
requisitos e suas restrições;

Projetar uma solução que atenda todos os requisitos e
restrições. Examinar o projeto cuidadosamente e ter certeza
que todas as partes interessadas concordam que essa é a
solução certa;

Fazer a implementação do projeto, usando as melhores
técnicas de engenharia ;

Verificar se a solução atende aos requisitos
estabelecidos;

Distribuir o produto.

Esse processo é similar à forma a qual pontes e edifícios
são construídos. Algumas coisas devem ser feitas dessa
maneira. Em um projeto com dois meses de duração, essa
metodologia poderia ser usada. Mas normalmente, softwares não
devem ser desenvolvidos dessa forma.

2.2 Método Iterativo e Incremental

O método iterativo foi criado para superar as dificuldades
impostas pelo modelo cascata. Já que o modelo cascata pode ser
usado com sucesso em projetos pequenos, onde o domínio do
problema é bem conhecido, a solução encontrada foi dividir
grandes projetos em projetos menores.

Dessa maneira, alguns requisitos e alguns riscos podem ser
identificados, um projeto pode ser realizado, uma
implementação pode ser construída para esse projeto, validada
e testada. Esse processo se repete com outras partes do
sistema até que o sistema inteiro seja terminado. Isso é
chamado de modo iterativo.

Em cada pequena parte do sistema é feita uma iteração. A
iteração segue o modelo seqüencial tradicional, com
identificação de necessidades, análise, projeto, implementação
e testes. A cada iteração o sistema é incrementado até que o
ciclo de desenvolvimento do aplicativo termine. Nesse ponto,
um novo ciclo de desenvolvimento pode ser iniciado.

A maneira de desenvolver projetos através de várias
iterações que vão incrementando o projeto até que se chegue a
um objetivo é chamada de modo iterativo e incremental.
Atualmente esse paradigma de desenvolvimento é bem aceito e
vem sendo utilizado por várias metodologias de desenvolvimento
de software.

3. O Rational Unified Process

Conforme [Kroll e Kruchten 2003], podemos ter três
definições para o Rational Unified Process (RUP):

O RUP é uma maneira de desenvolvimento de software que é
iterativa, centrada à arquitetura e guiada por casos de uso.
É descrita em vários livros e artigos. Uma das maiores
fontes de informações é o próprio produto IBM RUP [1], que contém guias detalhados, exemplos
e modelos cobrindo todo o ciclo de vida do software;

O RUP é um processo de engenharia de software bem
definido e bem estruturado. O RUP define claramente quem é
responsável pelo que, como as coisas devem ser feitas e
quando fazê-las. O RUP também provê uma estrutura bem
definida para o ciclo de vida de um projeto RUP, articulando
claramente os marcos essenciais e pontos de decisão;

O RUP é também um produto de processo que oferece uma
estrutura de processo customizável para a engenharia de
software. O produto IBM RUP suporta a customização e autoria
de processos, e uma vasta variedade de processos, ou
configuração de processos, podem ser montadas nele. Essas
configurações do RUP podem ser criadas para suportar equipes
grandes e pequenas, e técnicas de desenvolvimento
disciplinadas ou menos formais. O produto IBM RUP contém
várias configurações e visões de processos prontas que guiam
analistas, desenvolvedores, testadores, gerentes de projeto,
gerentes de configuração, analistas de dados, e outros
membros da equipe de desenvolvimento em como desenvolver o
software. Ele tem sido utilizado por muitas companhias em
diferentes setores da indústria.

O RUP utiliza a Linguagem Unificada de Modelagem (UML[2]) para especificar, modelar e documentar
artefatos. A UML é um padrão definido pelo OMG[3]
e ter se tornado o padrão empresarial para a modelagem
orientada a objetos[4].

Por ser flexível e configurável, o RUP pode ser utilizado
em projetos de pequeno, médio e grande porte. [Kroll e
Kruchten 2003] mostra como o RUP pode ser utilizado em um
projeto de uma semana com uma equipe de uma pessoa.

3.1 Os Princípios do RUP

Não existe uma maneira exata de aplicar o RUP, pois ele
pode ser aplicado de várias formas e será diferente em cada
projeto e organização. Porém, existem alguns princípios que
podem caracterizar e diferenciar o RUP de outros métodos
iterativos:

Atacar os riscos cedo e continuamente;

Certificar-se de entregar algo de valor ao cliente;

Focar no software executável;

Acomodar mudanças cedo;

Liberar um executável da arquitetura cedo;

Construir o sistema com componentes;

Trabalhar junto como um time;

Fazer da qualidade um estilo de vida, não algo para
depois.

3.2 Elementos do RUP

O RUP possui cinco elementos principais: papéis,
atividades, artefatos, fluxos de trabalho e disciplinas.

Um papel (ou perfil) define o comportamento e as
responsabilidades de um determinado indivíduo ou grupo de
indivíduos trabalhando como uma equipe. Papéis não são
indivíduos e nem títulos de trabalho. Um indivíduo pode
assumir vários papéis. São exemplos de papéis:

Analista de sistema – O indivíduo que assume este papel
coordena a obtenção dos requisitos e a modelagem dos casos
de uso identificando funcionalidades do sistema e
estabelecendo limites do sistema;

Projetista – Esse indivíduo define responsabilidades,
operações, atributos, relacionamentos de uma ou mais classes
e determina como elas devem ser ajustadas para serem
implementadas no ambiente;

Projetista de testes – Responsável pelo planejamento,
projeto, implantação e avaliação de testes, incluindo a
geração de plano e modelo de teste, implementando
procedimentos de testes e avaliando a abrangência dos
testes, resultados e a efetividade.

Uma atividade é uma unidade de trabalho que um indivíduo
executa quando está exercendo um determinado papel e produz um
resultado importante para o contexto do projeto. Cada
atividade pode ser dividida em passos. São exemplos de
atividades:

Planejar uma iteração: realizada pelo papel gerente de
projeto;

Encontrar casos de uso e atores: realizada pelo papel
analista de sistemas;

Rever o projeto: realizada pelo papel revisor de
projeto;

Executar um teste de performance: realizado pelo papel
testador de performance.

Um artefato é um pedaço de informação que é produzido,
modificado ou utilizado em um processo. Os artefatos são os
produtos de um projeto. São as coisas produzidas durante o
desenvolvimento do projeto. Artefatos são utilizados como
entradas de atividades e são produzidos como saída. Os
artefatos podem ter várias formas:

Um modelo, como um modelo de caso de uso, um modelo de
projeto;

Um elemento de um modelo, como uma classe, um caso de
uso, um sub-sistema ;

Um documento, como um caso de negócio, glossário, visão;

Código fonte;

Executáveis.

A enumeração de atividades, papéis e artefatos não
constituem um processo. É necessário saber a seqüência do
desenvolvimento das atividades para que possam ser produzidos
artefatos de valor para o projeto. Um fluxo de trabalho[5]
é uma seqüência de atividades que são executadas para a
produção de um resultado valioso para o projeto. Fluxos de
trabalho podem ser representados por diagramas de seqüência,
diagramas de colaboração e diagramas de atividades da
linguagem UML. O RUP utiliza três tipos de fluxos de trabalho:

Fluxos de trabalho principais, associados com cada
disciplina (figura 2);

Fluxos de trabalho de detalhe, para detalhar cada fluxo
de trabalho principal (figura 3);

Planos de iteração, que mostram como a iteração deverá
ser executada.

Figura 2: Fluxo de trabalho: requisitos

Figura 3 :Detalhamento de fluxo de trabalho:
analisar o problema

Uma disciplina é uma coleção de atividades relacionadas que
fazem parte de um contexto comum em um projeto. As disciplinas
proporcionam um melhor entendimento do projeto sob o ponto de
vista tradicional de um processo cascata. A separação das
atividades em disciplinas torna a compreensão das atividades
mais fácil, porém dificulta mais o planejamento das
atividades. O RUP possui nove disciplinas, divididas em
disciplinas do processo e de suporte. As disciplinas de
processo são: modelagem de negócios, requisitos, análise e
projeto, implementação, teste e distribuição. As de suporte
são: configuração e gerenciamento de mudanças, gerenciamento
de projeto, e ambiente.

Figura 4: Arquitetura geral do RUP

Conforme mostra a figura 4, o RUP possui duas dimensões:

O eixo horizontal representa o tempo e mostra os
aspectos do ciclo de vida do processo à medida que se
desenvolve. Representa o aspecto dinâmico do processo. É
expresso em termos de fases, disciplinas e marcos.

O eixo vertical representa as disciplinas, que agrupam
as atividades de maneira lógica, por natureza. Representa o
aspecto estático do processo. É descrito em termos de
componentes, disciplinas, atividades, fluxos de trabalho,
artefatos e papéis do processo.

3.3 O Ciclo de Vida de um Projeto RUP

O ciclo de desenvolvimento no RUP possui quatro fases:
iniciação[6],
elaboração, construção e transição. Cada uma é concluída por
um marco principal, ou seja, cada fase é basicamente um
intervalo de tempo entre dois marcos principais, como é
mostrado na figura 5.

Figura 5: As fases e os marcos de um projeto

O ciclo de desenvolvimento termina com uma versão completa
do produto de software. As fases definem estados do projeto,
que são definidos por riscos que estão sendo mitigados ou
questões que precisam ser respondidas.

A fase de iniciação, foca no tratamento de riscos
relacionados com o caso de negócio. Deve ser verificado se o
projeto é viável e se é financeiramente possível.

Na fase elaboração, o foco deve ser nos riscos técnicos e
arquiteturais. O escopo deve ser revisado e os requisitos
devem estar mais compreendidos.

Durante a construção, a atenção será voltada para os riscos
“lógicos”, e a maior parte do trabalho será realizada.

Na fase de transição, serão tratados os riscos associados
com a logística de distribuição do produto para a base de
usuários.

Embora varie muito em empresas e projetos diferentes, um
ciclo de desenvolvimento para um projeto de
tamanho médio, possui uma distribuição de esforço e
programação como é apresentado na tabela 1 e na figura 6.

Tabela 1. Distribuição de esforço e programação em projetos
de médio porte.

Figura 6: Distribuição de esforço e
programação em projetos de médio porte.

Conforme descrito na documentação do RUP, cada passagem
pelas quatro fases gera uma geração do software. A menos que o
produto "desapareça", ele irá se desenvolver na próxima
geração, repetindo a mesma seqüência de fases de iniciação,
elaboração, construção e transição. Esses ciclos subseqüentes
são chamados de ciclos de evolução. A cada
ciclo, são produzidas novas gerações.

Os ciclos de evolução podem ser disparados por melhorias
sugeridas pelos usuários, mudanças no contexto do usuário,
mudanças na tecnologia subjacente, reação à concorrência e
assim por diante. Normalmente, a menos que ocorram mudanças
significativas do produto ou da arquitetura, os ciclos de
evolução têm fases de Iniciação e Elaboração bem menores, pois
a definição e a arquitetura básicas do produto foram
determinadas por ciclos de desenvolvimento anteriores.

4. Conclusão

Com a utilização de uma metodologia de desenvolvimento de
software como o RUP, é possível obter:

Qualidade de software;

Produtividade no desenvolvimento, operação e manutenção
de software;

Controle sobre desenvolvimento dentro de custos, prazos
e níveis de qualidade desejados;

Estimativa de prazos e custos com maior precisão.

Apesar dos benefícios, deve-se ter a consciência que os
benefícios não virão de maneira imediata. É necessário
adquirir treinamento adequado, adaptação da metodologia no
contexto ao qual ela será utilizada, apoio especializado para
as equipes de desenvolvimento e tempo para a absorção da
metodologia.

Mais informações a respeito do RUP podem ser obtidas no
site do IBM RUP e também no site da comunidade IBM Rational .
(IBM 2004).

Referências

Comunidade IBM RUP (2004)
http://www-130.ibm.com/developerworks
/rational/community,Novembro.

Fowler, Martin (2003) “UML Distilled: A Brief Guide to the
Standard Object Modeling Language”, Addison Wesley, 3ª Edição.

IBM Rational Unified Process Versão 2003.06.12.01 . (2004)
http://www-306.ibm.com/software/rational, Novembro.

IBM RUP (2004)
http://www-130.ibm.com/developerworks/rational/products/rup,Novembro.

Kroll, P. e Kruchten P. (2003) “The Rational Unified
Process Made Easy: A Practitioner's Guide to the RUP”, Addison
Wesley.

Kruchten, P. (2003) “The Rational Unified Process: An
Introduction”, Addison Wesley, 3ª Edição .

Larman, Craig (2001) “Applying UML and Patterns – An
Introduction to Object-Oriented Analysis and Design and the
Unified Process”, Prentice Hall, 2ªEdição .

Object Management Group (2004) http://www.omg.org,
Novembro.

Perrelli, Hermano (2004) “Visão Geral do RUP”. Centro de
Informática, Universidade Federal de Pernambuco.
http://www.cin.ufpe.br/~if717/slides/3-visao-geral-do-rup.pdf,
Novembro.

[1]Após a compra da Rational pela IBM, o
produto Rational Unified Process passou a se chamar IBM
Rational Unified Process (IBM RUP).

[2]UML: Abreviatura do inglês Unified Modeling
Language. [Fowler 2003] é uma ótima referência para esse
assunto.

[3]OMG: Object Management Group.

[4]Consulte [Larman 2001] para informações
sobre aplicação da UML para análise e projeto orientados a
objeto

[5]O termo fluxo de trabalho vem do termo
inglês workflow. Pode ser traduzido também como fluxo de
atividade.

[6]Iniciação é a tradução do termo inglês
“inception”. Esse termo é também traduzido como
“concepção”.

Nota sobre o autor

Ronaldo Rezende
Vilela Luiz estará cursando o 8º e último período do
curso de Sistemas de Informação da Universidade de Uberaba no
primeiro semestre de 2005. É um dos administradores e
fundadores do portal OODesign. Incentiva o uso de metodologias de
desenvolvimento, de qualidade de software e de software
livre.

Copyright © por JavaFree.com.br - O diferencial
da comunidade Java no Brasil. Todos os direitos
reservados.

Publicado em: 2004-12-07 (1202
vizualização(ões))

[ Voltar
]

Content
©

Web site engine's code is
Copyright © 2002 by PHP-Nuke. All Rights Reserved. PHP-Nuke is Free
Software released under the GNU/GPL license.
Tempo para gerar esta
página: 0.381 segundos